? To: gregra @ cc.bellcore.com @ rtpsmtp cc: raoc @ vnet.ibm.com @ rtpsmtp, douglas.g.oleary @ bell-atl.com @ rtpsmtp, lgreenstein @ nuera.com @ rtpsmtp, malis @ maelstrom.Timeplex.com @ rtpsmtp, ptam @ bnr.ca @ rtpsmtp, gmattson @ baynetworks.com @ rtpsmtp, kjr @ netrix.com @ rtpsmtp, kawa @ bnr.ca @ rtpsmtp, frftc @ frforum.com @ rtpsmtp From: David Sinicrope Date: 05-20-96 01:55:32 PM Subject: "No" Recommendation to Proposed X.76 Security: ------------------------------ Mr. Ratta, As per your discussion with Mr. Rao Cherukuri, I received the following comments after distributing the proposed X.76 to the Frame Relay Forum Technical Committee. Given the significance of the comments and the absence of opposing views, we recommend that the US not approve the current version of X.76. Although we agree with the concepts and general function of X.76, we also believe that the issues below need to be resolved before the document is approved. Please contact me if you have any questions or concerns. Regards David Sinicrope IBM Research Triangle Park, NC ---------------------------------------------------- To: David Sinicrope cc: From: RAOC @ RALVM6 Date: 05-17-96 03:50:43 PM Subject: Security: Date: 17 May 96, 14:38:21 EDT From: RAOC at RALVM6 To: SINICROP at RTPNOTES, lgreenstein at nuera.com, malis at maelstrom.Timeplex.com, douglas.g.oleary at bell-atl.com, ptam at bnr.ca, gmattson at baynetworks.com, kjr at netrix.com, kawa at bnr.ca CC: frftc at frforum.com Subject: Review of X.76 David and all, I am including my comments, Claude Kawas and Andy Malis comments on X.76. I spoke to Mr. Greg Ratta from Bellcore. He is obtaining comments from T1S1 members. Greg Ratta will inform State Department on Monday. We have to provide our input to him by Monday noon. Please provide your comments based on your review as well as these comments to David Sinicorpe. Regards Rao Cherukuri ************************** Rao Cherukuri's Comments Subject: Comments on X.76 I reviewed the Recommendation X.76 (SVC Part) contained in the TD 2294 SG 7, April 1996. The Frame Relay NNI facilities requires are not completed. They require additional work. The current Recommendation will cause interoperability problems to support existing Q.933 based networks. The major problems are given below: 1. Transit network selection is for further study. In US it is a mandatory item. 2. Page 57 Mandatory information element content error The changes to first bullet will cause problems for interoperability with Q.933 networks, ATM networks using Q.2931. Further it also provide difficulty in adding additional capabilities by modifying the existing mandatory information elements. 3. Transit network identification Needs additional work. Why it is needed if clearing network id is included in the call clearing messages. 4. Call identification Based on the X.36 (10.6.1.2 Calling number screening and presentation), it is not possible to have unique identifier for each SVC. 5. Reverse charging Additional procedures are needed to support this capability. It is not clear when the next network does not support this capability. How the calling user knows whether call is reverse changed or not? From above identified problems, it is clear that the proposed X.76 requires additional work. I believe they are serious and a NO should be considered. Regards Rao Cherukuri IBM Research Triangle Park, NC ************************* Claude Kawa's Comments To: raoc@vnet.ibm.com Subject: comments on X.76 Return-receipt-to: kawa@nortel.ca Rao These are the issues we discussed, I identified others. I believe they are serious and a NO should be considered] I am back on tuesday May 21. Some issues with X.76 Item 1 page 14 section 10.4.9 SETUP Transit network selection IE is not supported at the NNI except if Q.933 is used at the UNI. It is possible that in some countries the regulator stipulates that subscribers should be allowed to select multiple transit networks. For this case X.76 should support the transit network information element. Also If the transit network information element is not supported at the NNI and one network supports multiple transit network selection and the other does not, the call will not be able to progress] Item 2: Page 54 section 10.6.5.3: A global call reference is allowed in the RESTART and STATUS ENQUIRY message. According to the text if these two messages are received with the global call reference, a STATUS is returned with cause # 81 "invalid call reference" this is incorrect] The solution is to indicate except STATUS ENQUIRY and RESTART messages. Item 3: page 57 Mandatory information element content error The first bullet states that an information element with a length greater than the maximum length should be consider as valid This rule will lead to wrong behavior for the following reason: Suppose in a new version of X.76 an information element is extended an implementation of the old version of X.76 will treat this new IE as valid but will discard the new added octets. this is incorrect. As an example new octets were added to Q.933 frame relay link layer core parameters, ignoring these additional octets by an old equipment would have caused an incorrect selection of the committed and excess burst sizes. The correction is to return to the previous rule and delete this one. Item 4 page 61 section 10.6.9.1 transit network identification It is mentionned (3rd line) that transit network identification is used for accounting, operations and routing control purposes. Questions requiring some clarifications in X.76: Q1-How this facility is used for accounting, operations and routing purposes? Q2-Why this facility needs to be included in the first clearing message? Q3-If the calling DTE can specify only one transit network selection why is it allowed to have up to 6 transit network identification? Q4-If the calling DTE can select one transit network only, can other transit networks be part of the call without the knowledge of the calling DTE/user? Q5-What happens if a network does not include its network id? Q6-There are two types of network identification one for network using E.164 and one for network using X.121. Many networks supports both numbering plans? what are the rules for using the network identification? Which network id to use? (See 10.5.2.1 also). Item 5 page 61 section 10.6.9.2 Call identification It is stated that "call identification provides a method to uniquely identify a SVC". Issues with the current text: 1- Must the call identification be different or can it be the same for each call? To assure uniqueness it seems that the call must be different. This point needs clarifications. 2-The calling party number used for the call is not necessarily the one used for accounting (this happens when multiple numbers are assigned a DTE. There is a need to specify what should be done in this case. 3-It is possible that 2 calls from the same DTE pass through different NNI and be assigned the same call identification (generated by two different network nodes or STE). Since this is possible the call identification will not uniquely identify a call] This example contradicts the purpose of the call identification. These are important issues, X.76 should be corrected. item 6 page 62 10.6.9.4 Reverse charging It is stated that reverse charging is supported by bilateral agreements. Suppose network A and B supports revers charging but not network C. A call has to go through A B and C in that order. What will do network B? Clear the call and be the clearing network. Further does it matter for a transit network to support reverse charging or not? reverse charging is mainly an access network issue] These issues needs to be clarified. item page 63 section 7 10.6.9.5 Clearing network identification Q1-What happens if a network does not provide its clearing network identification? or provide a wrong one? Should the correctness of the network id be checked? If yes what should be done? If not what is then the value of an information which might not be necessarily correct? Q2-What to do if inadvertently or not a network another network delete the clearing network identification or put it in a different position than the last one? Q3-Why multiple network identification are needed in the first clearing message? Claude ************************************ Andy Malis Comments To: David Sinicrope , Claude Kawa cc: malis@nexen.com, "douglas.g.oleary" , raoc Subject: Re: Review of X.76 In-reply-to: Your message of "15 May 1996 11:36:16." <9605151556.AA0208@rtpnsi01.raleigh.ibm.com> Date: Wed, 15 May 1996 15:08:17 -0400 Resent-To: raoc Resent-Date: Wed, 15 May 1996 15:20:25 -0400 Resent-From: "Andrew G. Malis" David and Claude, Thanks for the info. Here are my comments on the issues mentioned: > The facilities US carriers need to review are defined in section > 10.6.9 and Appendix VI of X.76. In particular the following ones: > > 1-FR network identification when E.164 numbering plan is used. > - A new network id is being proposed when E.164 numbers are used. > The max size is 8 octets. There is not yet a registration > procedure neither in ITU nor in the US. Is the size OK? Not too > long? I don't think 8 octets is too long, since we don't want to repeat the mistake make in X.121, where the DNIC field was much too small. Since E.164 assigns country codes of up to three digits, this leaves at least five digits per country, which I don't believe to be excessive. I thought Appendix VI was reasonable with regard to discussion registries. I assume the ITU now maintains a central X.121 DNIC registry; why is this any different? As the appendix notes, the actual assignment is a national matter. For the US, Greg Miller pointed out in FRF96-044 (Las Vegas meeting) that the FRF has already been designated as the US administrative agency for the North American (area 1) FR network identification plan. I did notice one editorial typo in Appendix VI. In the fourth line of the first paragraph, "8 octets code according" should read "8 octets coded according". In that same phrase, I also recommend replacing "8" with "eight". I am much more concerned with the limit of six network identification information elements. Is there a technical reason for this limit? If NNIs and FR SVCs are as successful worldwide as we would like them to be, then I can easily imagine international calls with more than six networks in the path. I know we need some limit, but is six too small? Let's avoid shooting ourselves in the foot here. > 2-Clearing Network identification > This facility indicates which network cleared the call. Is it > desirable in the US to indicate which network cleared the call in a > competitive environment? Absolutely. This is extremely important ESPECIALLY in a competetive environment. Let me give you an example. I own and run network A, with a peering agreement with network B, which has a peering agreement with network C. A customer of mine keeps having calls cleared to one of network C's customers. He tells me that he is going to find another provider if this persists. As operator, I want to know (and also want my customer to know) where the fault is occuring. If it is in my own network, I can take appropriate action. If it is in B's network, and this customer is important enough to me, then I can get a direct peering relationship with C. If it is in C's network, I want to be able to tell the customer that the calls are going to continue to be cleared unless C corrects the problem or his friend on C's network moves elsewhere. Without the clearing network ID, I have no idea how to either correct the problem or assure my customer that the problem is elsewhere. If I am at fault, I'm willing to publicly own up to it if that's the cost of finding out when I'm NOT at fault as well. > 3-Transit Network identification > This facility is used for accounting settlement. It has been > borrowed from X.75 because of the underlying assumption that FR > service is offered by X.25/X.75 networks. Is it align with the > practice in the US? I don't think that using TNI requires that FR service be provided by an underlying X.25/X.75 network. There's no reason why interconnected FR networks can't use it in the NNI signaling, even if the service is provided by native FR or cell-based switches (both of which I believe are much more common in the FR market than native X.25/X.75 switches these days, and this is coming from a person that used to build X.25/X.75 switches in a former life). The FR business practice these days is PVCs. There are no SVC-based NNIs in existance, at least that I'm aware of (please enlighten me if I'm wrong). This gives us the chance to define TNI's use at the FR NNI if it's the right thing to do, regardless of the underlying switch technology. > We need to provide an answer (YES or NO) whether the US approves > X.76 by next week so that the Department of State can send it to > ITU-T secretariat. I hope this helps you formulate your answer. > About the priority, we were not able to get it in this version of > X.36 and X.76 there was a strong opposition from a Canadian company > but others who support it express the need to simplify it. As > editor I was assigned the task to draft a specification by July. We > will be hosting an interim meeting in Ottawa in September. I will > extend the invitation to the FR forum members also. > Other items for the interim meeting: > - Access to frame relay network from an ISDN > - support of multiprotocol encapsulation ver FR SVC I'll be happy to review your draft specification, and I would very much like to attend the interim meeting. Please avoid, if possible, September 13 (Rosh Hashanah) and September 23 (Yom Kippur), as I would be unable to attend on those dates. Also, Interop is the week of September 16, and I'm sure that many people would like to avoid that conflict as well. Cheers, Andy -------------------------------------------------------- David A. Sinicrope IBM Corporation CE6A/664 800 Park Offices Dr. RTP, NC 27709 Telephone: +1 919 254 1207 FAX: +1 919 254 5483 IBM Internal: DAVID at RTP Inter-enterprise Mail: USIB1MWT at IBMMAIL Internet: david@vnet.ibm.com